Correctness By Construction: Better Can Also Be Cheaper

I n December 1999 CrossTalk [3], David Cook provided a well-reasoned historical analysis of programming language development and considered the role languages play in the software development process. The article was valuable because it showed that programming language developments are not sufficient to ensure success; however, it would be dangerous to conclude from this that they are not necessary for success. Cook rightly identifies other issues such as requirements capture, specifications, and verification and validation (V&V) that need to be addressed. Perhaps we need to look at programming languages not just in terms of their ability to code some particular design but in the influence the language has on some of these other vital aspects of the development process. The key notion is that of the benefit of a precise language or language subset. If the term subset has set anyone thinking " oh no, not another coding standard, " then read on, the topic is much more interesting and useful than that! Language Issues Programming languages have evolved in three main ways. First came improvements in structure; then attempts at improving compile-time error detection through such things as strong typing; and, most significantly , facilities to improve our ability to express abstractions. All of these have shaped the way we think about problem solving. However, programming languages have not evolved in their precision of expression. In fact, they may have actually gotten worse since the meaning of a sample of machine code is exact and unequivocal , whereas the meaning of the constructs of typical modern high-order languages are substantially less certain. The evolution of C into C++ certainly improved its ability to express design abstractions but, if anything, the predictability of the compiled code decreased. These ambiguities arise either from deficiencies in the original language definition or from implementation freedoms given to the compiler writer for ease of implementation or efficiency reasons. None of this may look like a very serious problem. We can still do code walk-throughs and reviews and, after all, we still have to do dynamic testing that should flush out any remaining ambiguities. In fact the evidence is quite strong that it does matter because it creates an environment where we are encouraged to make little attempt to reason about the software we are producing at each stage of its development. Since we typically do not have formal mathematical specifications and we use imprecise …